node/cn: verify a blob tx sidecar only once - #1012

A replayed blob transaction is decoded into a fresh sidecar object, so the
sidecar's own validation cache never hits and the handler verified its KZG
proofs again on every copy. One single-blob v1 sidecar measures ~15.5ms, and a
12MiB TxMsg fits about 90 of them, so a captured transaction could be resent
indefinitely at no cost to the sender. The handler now keeps a bounded set of
blob tx hashes it already verified and skips the verification for those.

Constraint: the tx pool verifies the sidecar independently before admitting a transaction, so skipping the early check cannot let a bad sidecar through
Rejected: reject duplicate hashes within one message | subsumed, the set already skips the repeats inside a single batch
Rejected: global KZG semaphore or per-peer token buckets | the repeated verification is what made a small message expensive, and bounding concurrency would also delay legitimate propagation
Confidence: high
Scope-risk: narrow
Not-tested: a rotating set of distinct captured blob txs still costs one verification each, which is bandwidth-bound

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The set was keyed by transaction hash, which does not cover the sidecar. A sender
could bump the nonce to replay one sidecar under unlimited distinct hashes, so every
copy missed the set and paid a full verification, and a sidecar swapped under an
already verified hash hit the set and skipped verification entirely.

Key the set by what the verification consumes instead: the blob hashes, the sidecar
version, its blobs and its proofs. Commitments are excluded because each blob hash is
the sha256 of one, so the hashes already pin them.

Also reject a blob transaction that declares no blob hashes. Every length check in
the verification compares against the declared hashes, so it passes vacuously, while
the pool rejects such a transaction unconditionally - the handler forwarded something
that could never be valid and left the sender connected.

Constraint: the key has to cover the blobs, not only the proofs, since the proofs are
  verified against them
Rejected: keep the transaction hash and add a sidecar fingerprint | any key that omits
  the blobs is bypassable the same way
Confidence: high
Scope-risk: narrow
Not-tested: a rotating set of distinct captured blob txs still costs one verification
  each, which is bandwidth-bound

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The key left out the commitments, on the grounds that each blob hash is the
sha256 of one. That binding is enforced by ValidateBlobCommitmentHashes, which
is exactly what a cache hit skips, so a commitment could be swapped under an
already verified sidecar: the key still matched, the verification never ran, and
the peer stayed connected where it is otherwise dropped. The elements are also
fixed-size and were concatenated without their counts, so sidecars of different
shapes encode to the same bytes and share a key the same way.

Add the commitments and prefix the four element counts. The key is then an
injective encoding of everything ValidateWithBlobHashes reads, so a cache hit
means that exact input passed before and the handler rejects what it rejected
before this cache existed.

Constraint: anything the verification reads has to be in the key, since the key
  decides whether the verification runs at all
Rejected: keep the commitments out and rely on the hashes | the check that ties
  them together is the one being skipped
Rejected: encode with RLP instead of prefixing counts | copies the whole sidecar
  into a buffer before hashing, on the path this cache exists to keep cheap
Confidence: high
Scope-risk: narrow
Not-tested: the count prefix has no test of its own

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>